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Les 


Introduction 


This document describes the configuration of proactive MPLS-TP OAM 
functions for a given LSP using TLVs that use GMPLS RSVP-TE 
[RFC3473]. [RFC7260] defines use of GMPLS RSVP-TE for the 
configuration of OAM functions in a technology-agnostic way. This 
document specifies the additional mechanisms necessary to establish 
MPLS-TP OAM entities at the maintenance points for monitoring and 
performing measurements on an LSP, as well as defining information 
elements and procedures to configure proactive MPLS-TP OAM functions 
running between Label Edge Routers (LERs).  Initialization and 
control of on-demand MPLS-TP OAM functions are expected to be carried 
out by directly accessing network nodes via a management interface; 
hence, configuration and control of on-demand OAM functions are out 
of scope for this document. 


MPLS-TP, the Transport Profile of MPLS, must, by definition 
[RFC5654], be capable of operating without a control plane. 
Therefore, there are several options for configuring MPLS-TP OAM 
without a control plane by using either a Network Management System 
(NMS), an LSP Ping, or signaling protocols such as RSVP-TE in the 
control plane. 


MPLS-TP describes a profile of MPLS that enables operational models 
typical in transport networks while providing additional OAM 
survivability and other maintenance functions not currently supported 
by MPLS.  [RFC5860] defines the requirements for the OAM 
functionality of MPLS-TP. 


Proactive MPLS-TP OAM is performed by three different protocols: 
Bidirectional Forwarding Detection (BFD) [RFC6428] for Continuity 
Check / Connectivity Verification, the Delay Measurement (DM) 
protocol [RFC6374] for delay and delay variation (jitter) 
measurements, and the Loss Measurement (LM) protocol [RFC6374] for 
packet loss and throughput measurements. Additionally, there are a 
number of Fault Management signals that can be configured [RFC6427]. 


BFD is a protocol that provides low-overhead, fast detection of 
failures in the path between two forwarding engines, including the 
interfaces, data link(s), and (to the extent possible) the forwarding 
engines themselves.  BFD can be used to track the liveliness and to 
detect the data plane failures of MPLS-TP point to point and might 
also be extended to support point-to-multipoint connections. 


The delay and loss measurement protocols [RFC6374] use a simple 
query/response model for performing bidirectional measurements that 
allows the originating node to measure packet loss and delay in both 
directions. By timestamping and/or writing current packet counters 
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to the measurement packets four times (Tx and Rx in both directions), 
current delays and packet losses can be calculated. By performing 
successive delay measurements, the delay variation (jitter) can be 
calculated. Current throughput can be calculated from the packet 
loss measurements by dividing the number of packets sent/received 
with the time it took to perform the measurement, given by the 
timestamp in LM header. Combined with a packet generator, the 
throughput measurement can be used to measure the maximum capacity of 
a particular LSP. It should be noted that here we are not 
configuring on-demand throughput estimates based on saturating the 
connection as defined in [RFC6371]. Rather, we only enable the 
estimation of the current throughput based on loss measurements. 
1.1. Conventions Used in This Document 
1.1.1. Terminology 
AIS - Alarm Indication Signal 
BFD - Bidirectional Forwarding Detection 
CC - Continuity Check 
CV - Connectivity Verification 
DM - Delay Measurement 
FMS - Fault Management Signal 
G-ACh - Generic Associated Channel 
GMPLS - Generalized Multi-Protocol Label Switching 
LDI - Link Down Indication 
LER - Label Edge Router 
LKR - Lock Report 


LM - Loss Measurement 


LOC Loss Of Continuity 


LSP 


Label Switched Path 


LSR - Label Switching Router 


MEP - Maintenance Entity Group End Point 
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MIP - Maintenance Entity Group Intermediate Point 
MPLS - Multi-Protocol Label Switching 
MPLS-TP - MPLS Transport Profile 
NMS - Network Management System 
PM - Performance Measurement 
RSVP-TE - Reservation Protocol Traffic Engineering 
TC - Traffic Class 
1.1.2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Overview of MPLS OAM for Transport Applications 


[RFC6371] describes how MPLS-TP OAM mechanisms are operated to meet 
transport requirements outlined in [RFC5860]. 


[RFC6428] specifies two BFD operation modes: 1) "CC mode", which uses 
periodic BFD message exchanges with symmetric timer settings 
supporting Continuity Check, and 2) "CV/CC mode", which sends unique 
maintenance entity identifiers in the periodic BFD messages 
supporting CV as well as CC. 


[RFC6374] specifies mechanisms for Performance Monitoring of LSPs, in 
particular it specifies loss and delay measurement OAM functions. 


[RFC6427] specifies fault management signals with which a server LSP 
can notify client LSPs about various fault conditions to suppress 
alarms or to be used as triggers for actions in the client LSPs. The 
following signals are defined: Alarm Indication Signal (AIS), Link 
Down Indication (LDI), and Lock Report (LKR). 


[RFC6371] describes the mapping of fault conditions to consequent 
actions. Some of these mappings may be configured by the operator 
depending on the application of the LSP. The following defects are 
identified: Loss Of Continuity (LOC), Misconnectivity, MEP 
Misconfiguration, and Period Misconfiguration. Out of these defect 
conditions, the following consequent actions may be configurable: 1) 
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whether or not the LOC defect should result in blocking the outgoing 
data traffic; 2) whether or not the "Period Misconfiguration defect" 
should result in a signal fail condition. 


3. Theory of Operations 
3.1. MPLS-TP OAM Configuration Operation Overview 


GMPLS RSVP-TE, or alternatively LSP Ping [LSP-PING-CONF], can be used 
to simply enable the different OAM functions by setting the 
corresponding flags in the OAM Function Flags Sub-TLV [RFC7260]. For 
a more detailed configuration, one may include sub-TLVs for the 
different OAM functions in order to specify various parameters in 
detail. 


Typically, intermediate nodes SHOULD NOT process or modify any of the 
OAM Configuration TLVs but simply forward them to the end node. 

There is one exception to this and that is if the MPLS OAM FMS Sub- 
TLV is present. This sub-TLV MUST be examined even by intermediate 
nodes that support these extensions but only acted upon by nodes 
capable of transmitting FMS signals into the LSP being established. 
The sub-TLV MAY be present when the FMS flag is set in the OAM 
Function Flags Sub-TLV. If this sub-TLV is present, then the "OAM 
MIP entities desired" and "OAM MEP entities desired" flags (described 
in [RFC7260]) in the LSP Attribute Flags TLV MUST be set and the 
entire OAM Configuration TLV placed either in the 
LSP_REQUIRED_ATTRIBUTES object or in the LSP_ATTRIBUTES object in 
order to ensure that capable intermediate nodes process the 
configuration. If placed in the LSP_ATTRIBUTES object, nodes that 
are not able to process the OAM Configuration TLV will forward the 
message without generating an error. If the MPLS OAM FMS Sub-TLV has 
been placed in the LSP_REQUIRED_ATTRIBUTES object, a node that 
supports RFC 7260 but does not support the MPLS OAM FMS Sub-TLV MUST 
generate a PathErr message with "OAM Problem/Configuration Error" 
[RFC7260]. Otherwise, if the node doesn’t support RFC 7260, it will 
not raise any errors as described in the Section 4.1 of [RFC7260]. 


Finally, if the MPLS OAM FMS Sub-TLV is not included, only the "OAM 
MEP entities desired" flag is set and the OAM Configuration TLV may 
be placed in either LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES. 
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3.1.1. Configuration of BFD Sessions 


For this specification, BFD MUST be run in either one of the two 
modes: 


o Asynchronous mode, where both sides should be in active mode; or 
o Unidirectional mode. 


In the simplest scenario, RSVP-TE (or alternatively LSP Ping 
[LSP-PING-CONF]), is used only to bootstrap a BFD session for an LSP 
without any timer negotiation. 


Timer negotiation can be performed either in subsequent BFD Control 
messages (in this case the operation is similar to LSP-Ping-based 
bootstrapping described in [RFC5884]) or directly in the RSVP-TE 
signaling messages. 


When BFD Control packets are transported in the G-ACh, they are not 
protected by any end-to-end checksum; only lower layers are providing 
error detection/correction. A single bit error, e.g., a flipped bit 
in the BFD State field, could cause the receiving end to wrongly 
conclude that the link is down and, in turn, trigger protection 
switching. To prevent this from happening, the BFD Configuration 
Sub-TLV has an Integrity flag that, when set, enables BFD 
Authentication using Keyed SHAl with an empty key (all Os) [RFC5880]. 
This would ensure that every BFD Control packet carries a SHA1 hash 
of itself that can be used to detect errors. 


If BFD Authentication using a pre-shared key / password is desired 
(i.e., authentication and not only error detection), the BFD 
Authentication Sub-TLV MUST be included in the BFD Configuration Sub- 
TLV. The BFD Authentication Sub-TLV is used to specify which 
authentication method should be used and which pre-shared key / 
password should be used for this particular session. How the key 
exchange is performed is out of scope of this document. 


3.1.2. Configuration of Performance Monitoring 
It is possible to configure Performance Monitoring functionalities 
such as Loss, Delay, Delay variation (jitter), and Throughput, as 
described in [RFC6374]. 
When configuring Performance Monitoring functionalities, it is 


possible to choose either the default configuration (by only setting 
the respective flags in the OAM Function Flags Sub-TLV) or a 
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customized configuration. To customize the configuration, one would 
set the respective flags and include the respective Loss and/or Delay 
sub-TLVs. 


By setting the PM/Loss flag in the OAM Function Flags Sub-TLV and by 
including the MPLS OAM PM Loss Sub-TLV, one can configure the 
measurement interval and loss threshold values for triggering 
protection. 


Delay measurements are configured by setting the PM/Delay flag in the 
OAM Function Flags Sub-TLV; by including the MPLS OAM PM Loss Sub- 
TLV, one can configure the measurement interval and the delay 
threshold values for triggering protection. 


3.1.3. Configuration of Fault Management Signals 


To configure Fault Management signals and their refresh time, the FMS 
flag in the OAM Function Flags Sub-TLV MUST be set and the MPLS OAM 
FMS Sub-TLV included. When configuring Fault Management signals, an 
implementation can enable the default configuration by setting the 
FMS flag in the OAM Function Flags Sub-TLV. In order to modify the 
default configuration, the MPLS OAM FMS Sub-TLV MUST be included. 


If an intermediate point is intended to originate fault management 
signal messages, this means that such an intermediate point is 
associated with a server MEP through a co-located MPLS-TP client/ 
server adaptation function, and the "Fault Management subscription" 
flag in the MPLS OAM FMS Sub-TLV has been set as an indication of the 
request to create the association at each intermediate node of the 
client LSP. The corresponding server MEP needs to be configured by 
its own RSVP-TE session (or, alternatively, via an NMS or LSP Ping). 


3.2. MPLS OAM Configuration Sub-TLV 


The OAM Configuration TLV, defined in [RFC7260], specifies the OAM 

functions that are used for the LSP. This document extends the OAM 
Configuration TLV by defining a new OAM Type: "MPLS OAM" (3). The 

MPLS OAM type is set to request the establishment of OAM functions 

for MPLS-TP LSPs. The specific OAM functions are specified in the 

OAM Function Flags Sub-TLV as depicted in [RFC7260]. 


When an egress LSR receives an OAM Configuration TLV indicating the 
MPLS OAM type, the LSR will first process any present OAM Function 
Flags Sub-TLV, and then it MUST process technology-specific 
configuration TLVs. This document defines a sub-TLV, the MPLS OAM 
Configuration Sub-TLV, which is carried in the OAM Configuration TLV. 
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0 1 2 3 

On 29034 566 Y B9 071 2^3 4 5-6 7.8 900.1 2.3 4-58 6 7 8 9.0.1 
dh hd Rd dd dd de dd dd dd de 4 B—MÁBMB—MBMMMÁ—MÁ B ++ +++ 
| MPLS OAM Conf. Sub-TLV (33) | Length | 
—————.—.-——R—R—R—R—R—R—R—R—R— RR 4 4 4 + + + +++ ++ +++ 
| | 


sub-TLVs 7 
—— ——— 
Figure 1: MPLS OAM Configuration Sub-TLV Format 
Type: 33, the MPLS OAM Configuration Sub-TLV. 


Length: Indicates the total length in octets, including sub-TLVs as 
well as the Type and Length fields. 


The following MPLS-OAM-specific sub-TLVs MAY be included in the MPLS 
OAM Configuration Sub-TLV: 


o BFD Configuration Sub-TLV MUST be included if either the CC, the 
CV, or both OAM Function flags are being set in the OAM Function 


Flags Sub-TLV [RFC7260]. This sub-TLV carries additional sub- 
TLVs; failure to include the correct sub-TLVs MUST result in an 
error being generated: "OAM Problem/Configuration Error". The 


sub-TLVs are: 
* BFD Identifiers Sub-TLV MUST always be included. 


* Timer Negotiation Parameters Sub-TLV MUST be included if the N 
flag is not set. 


* BFD Authentication Sub-TLV MAY be included if the I flag is 
set. 


o Performance Monitoring Sub-TLV, which MUST be included if any of 
the PM/Delay, PM/Loss, or PM/Throughput flags are set in the OAM 
Function Flag Sub-TLV [RFC7260]. This sub-TLV MAY carry 
additional sub-TLVs: 


* MPLS OAM PM Loss Sub-TLV MAY be included if the PM/Loss OAM 
Function flag is set. If the MPLS OAM PM Loss Sub-TLV is not 
included, default configuration values are used. The same sub- 
TLV MAY also be included in case the PM/Throughput OAM Function 
flag is set and there is the need to specify measurement 
intervals different from the default ones. Since throughput 
measurements use the same tool as loss measurements, the same 
TLV is used. 
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* MPLS OAM PM Delay Sub-TLV MAY be included if the PM/Delay OAM 
Function flag is set. If the MPLS OAM PM Delay Sub-TLV is not 
included, default configuration values are used. 


o MPLS OAM FMS Sub-TLV MAY be included if the FMS OAM Function flag 
is set. If the MPLS OAM FMS Sub-TLV is not included, default 
configuration values are used. 


The following are some additional rules of processing the MPLS OAM 
Configuration Sub-TLV: 


o The MPLS OAM Configuration Sub-TLV MAY be empty, i.e., have no 
Value. If so, then its Length MUST be 8. Then, all OAM functions 
that have their corresponding flags set in the OAM Function Flags 
Sub-TLV MUST be assigned their default values or left disabled. 


o A sub-TLV that doesn't have a corresponding flag set MUST be 
silently ignored. 


o If multiple copies of a sub-TLV are present, then only the first 
sub-TLV MUST be used and the remaining sub-TLVs MUST be silently 
ignored. 


However, not all the values can be derived from the standard RSVP-TE 
objects, in particular the locally assigned Tunnel ID at the egress 
cannot be derived by the ingress node. Therefore, the full LSP MEP- 
ID used by the ingress has to be carried in the BFD Identifiers Sub- 
TLV in the Path message and the egress LSP MEP-ID in the same way in 
the Resv message. 


3.2.1. CV Flag Rules of Use 


If the CV flag is set in the OAM Function Flags Sub-TLV [RFC7260], 
then the CC flag MUST be set as well because performing Connectivity 
Verification implies performing Continuity Check as well. The format 
of an MPLS-TP CV/CC message is shown in [RFC6428]. In order to 
perform Connectivity Verification, the CV/CC message MUST contain the 
"LSP MEP-ID" in addition to the BFD Control packet information. The 
"LSP MEP-ID" contains four identifiers: 


MPLS-TP Global ID 
MPLS-TP Node Identifier 
Tunnel Num 


LSP Num 
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These values need to be correctly set by both ingress and egress when 
transmitting a CV packet, and both ingress and egress need to know 
what to expect when receiving a CV packet. Most of these values can 
be derived from the Path and Resv messages [RFC3473], which use a 
5-tuple to uniquely identify an LSP within an operator's network. 
This tuple is composed of a Tunnel Sender Address, Tunnel Endpoint 
Address, Tunnel ID, Extended Tunnel ID, and (GMPLS) LSP ID. 


3.3. BFD Configuration Sub-TLV 


The BFD Configuration Sub-TLV (depicted below) is defined for BFD- 
OAM-specific configuration parameters. The BFD Configuration Sub-TLV 
is carried as a sub-TLV of the MPLS OAM Configuration Sub-TLV. 


This TLV accommodates generic BFD OAM information and carries sub- 
TLVs. 


0 1 2 3 
0123456789 0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


| BFD Conf. Type (1) | Length | 
A dd + dd — + dd + dd + $ 4 +++ ++ +++ A AE EA ELA 
|vers.|N|S|r|Glu|B| Reserved (set to all Os) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


n sub-TLVs B 

"TP eee ee ee ee eee S EE. 
Figure 2: BFD Configuration Sub-TLV Format 

Type: 1, the BFD Configuration Sub-TLV. 


Length: Indicates the total length in octets, including sub-TLVs as 
well as the Type and Length fields. 


Version: Identifies the BFD protocol version. If the egress LSR does 
not support the version, an error MUST be generated: "OAM Problem/ 


Unsupported BFD Version". 


BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD 
Control messages is enabled, when cleared it is disabled. 


Symmetric Session (S): If set, the BFD session MUST use symmetric 
timing values. 


Bellagamba, et al. Standards Track [Page 12] 


RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 


Integrity (I): If set, BFD Authentication MUST be enabled. If the 
BFD Configuration Sub-TLV does not include a BFD Authentication Sub- 
TLV, the authentication MUST use Keyed SHA1 with an empty pre-shared 


key (all Os). If the egress LSR does not support BFD Authentication, 
an error MUST be generated: "OAM Problem/BFD Authentication 
unsupported". 


Encapsulation Capability (G): If set, it shows the capability of 
encapsulating BFD messages into The G-Ach channel. If both the G bit 
and U bit are set, configuration gives precedence to the G bit. If 
the egress LSR does not support any of the ingress LSR Encapsulation 
Capabilities, an error MUST be generated: "OAM Problem/Unsupported 
BFD Encapsulation format". 


Encapsulation Capability (U): If set, it shows the capability of 
encapsulating BFD messages into UDP packets. If both the G bit and U 
bit are set, configuration gives precedence to the G bit. If the 
egress LSR does not support any of the ingress LSR Encapsulation 
Capabilities, an error MUST be generated: "OAM Problem/Unsupported 
BFD Encapsulation Format". 


Bidirectional (B): If set, it configures BFD in the Bidirectional 
mode. If it is not set, it configures BFD in unidirectional mode. 

In the second case, the source node does not expect any Discriminator 
values back from the destination node. 


Reserved: Reserved for future specifications; set to 0 on 
transmission and ignored when received. 


The BFD Configuration Sub-TLV MUST include the following sub-TLVs in 
the Path message: 


o BFD Identifiers Sub-TLV; and 
o Negotiation Timer Parameters Sub-TLV if the N flag is cleared. 


The BFD Configuration Sub-TLV MUST include the following sub-TLVs in 
the Resv message: 


o BFD Identifiers Sub-TLV; and 
o Negotiation Timer Parameters Sub-TLV if: 


* the N and S flags are cleared; or if 
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* the N flag is cleared and the S flag is set and the Negotiation 
Timer Parameters Sub-TLV received by the egress contains 
unsupported values. In this case, an updated Negotiation Timer 
Parameters Sub-TLV containing values supported by the egress 
LSR MUST be returned to the ingress. 


3.3.1. BFD Identifiers Sub-TLV 


The BFD Identifiers Sub-TLV is carried as a sub-TLV of the BFD 
Configuration Sub-TLV and is depicted below. 


0 1 2 3 
Op 2-234 56 T8 9-0 1 2 3.4 5-6-4^:8/9405L 2 3 4 46) 7.8.9.0 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
BFD Identifiers Type (1) | Length 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Local Discriminator | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
MPLS-TP Global_ID | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
MPLS-TP Node Identifier | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Tunnel_Num | LSP_Num | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ — + — + —+—+—+ 


Figure 3: BFD Identifiers Sub-TLV Format 
Type: 1, the BFD Identifiers Sub-TLV. 


Length: Indicates the TLV total length in octets, including the Type 
and Length fields (20). 


Local Discriminator: A unique, non-zero discriminator value generated 
by the transmitting system and referring to itself; it is used to de- 
multiplex multiple BFD sessions between the same pair of systems as 
defined in [RFC5880]. 


MPLS-TP Global_ID, Node Identifier, Tunnel_Num, and LSP_Num: All set 
as defined in [RFC6370]. 
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34 


3 


.2. Negotiation Timer Parameters Sub-TLV 


The Negotiation Timer Parameters Sub-TLV is carried as a sub-TLV of 
the BFD Configuration Sub-TLV and is depicted below. 


0 1 2 3 
0.1.2.3 4.56 78:9 0 1.2.3 4 5 6.758 9/0 1.2 3.4.5 6 7 (8,0901 1 
€——————————^A^A^—A—RARAA^—^————^2— —»^»——————— 
| Nego. Timer Type (2) | Length | 
€————————————A—^^AA—^—^A^R5 A ^ c »—»——»—»—»————————— o 

| Acceptable Min. Asynchronous TX interval 
€——€—€—————^^A^AR^A——A^A^A^A—»4^46»óAWWR5A^ e EE—————— 
| Acceptable Min. Asynchronous RX interval 
€——€————————————A————————A————— ——— 
| Required Echo TX Interval 
€——————^———^—^^A€^^A€A^A^A^A^AA A^AAAAeAA—A—^—^A^A^—AAR^ ARR ^ RÉ»A—»——»———»—————————— 


Figure 4: Negotiation Timer Parameters Sub-TLV Format 
Type: 2, the Negotiation Timer Parameters Sub-TLV. 


Length: Indicates the TLV total length in octets, including Type and 
Length fields (16). 


Acceptable Min. Asynchronous TX interval: If the S flag is set in the 
BFD Configuration Sub-TLV, it expresses the desired time interval (in 
microseconds) at which the ingress LER intends to both transmit and 
receive BFD periodic control packets. If the egress LSR cannot 
support the value, it SHOULD reply with a supported interval. 


If the S flag is cleared in the BFD Configuration Sub-TLV, this field 
expresses the desired time interval (in microseconds) at which the 
ingress LSR intends to transmit BFD periodic control packets. 


Acceptable Min. Asynchronous RX interval: If the S flag is set in the 
BFD Configuration Sub-TLV, this field MUST be set equal to 
"Acceptable Min. Asynchronous TX interval" on transmit and MUST be 
ignored on receipt since it has no additional meaning with respect to 
the one described for "Acceptable Min. Asynchronous TX interval". 


If the S flag is cleared in the BFD Configuration Sub-TLV, it 
expresses the minimum time interval (in microseconds) at which the 
ingress/egress LSRs can receive periodic BFD Control packets. If 
this value is greater than the "Acceptable Min. Asynchronous TX 
interval" received from the ingress/egress LSR, the receiving LSR 
MUST adopt the interval expressed in the "Acceptable Min. 
Asynchronous RX interval". 
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Required Echo TX 
between received 
supporting, less 
Section 6.8.9 of 
receiving system 


Interval: The minimum interval (in microseconds) 
BFD Echo packets that this system is capable of 
any jitter applied by the sender as described in 
[RFC5880]. This value is also an indication for the 
of the minimum interval between transmitted BFD Echo 


packets. If this value is zero, the transmitting system does not 
support the receipt of BFD Echo packets. If the LSR node cannot 
support this value, it SHOULD reply with a supported value (which may 
be zero if Echo is not supported). 


3.3.3. BFD Authentication Sub-TLV 


The BFD Authentication Sub-TLV is carried as a sub-TLV of the BFD 
Configuration Sub-TLV and is depicted below. 


0 
01234567 


1 2 3 
8.9 012345078959 0212. 3425072989 01 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 


| BFD Auth. 


Type (3) | Length | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 


| Auth Type | 


Auth Key ID | Reserved (0s) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 5: BFD Authentication Sub-TLV Format 


Type: 3, the BFD 


Authentication Sub-TLV. 


Length: Indicates the TLV total length in octets, including Type and 
Length fields (8). 


Auth Type: Indicates which type of authentication to use. The same 
values are used as are defined in Section 4.1 of [RFC5880]. If the 
egress LSR does not support this type, an "OAM Problem/Unsupported 
BFD Authentication Type" error MUST be generated. 


Auth Key ID: Indicates which authentication key or password 
(depending on Auth Type) should be used. How the key exchange is 


performed is out 
not support this 


of scope of this document. If the egress LSR does 
Auth Key ID, an "OAM Problem/Mismatch of BFD 


Authentication Key ID" error MUST be generated. 


Reserved: Reserved for future specifications; set to 0 on 


transmission and 
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3.3.4. Traffic Class Sub-TLV 


The Traffic Class Sub-TLV is carried as a sub-TLV of the BFD 
Configuration Sub-TLV or Fault Management Signal Sub-TLV 
(Section 3.5) and is depicted in Figure 6. 


0 1 2 3 
0123456789 0123456789012345678901 
TR RTRRRMRTRR BRE] RR] 

| Traffic Class Sub-Type (4) | Length 

dh A A A O O O A A A e O o o o o o o +++ 
| TC Reserved (set to all 0s) 

dh A A A O O O A A A e O O o o o o o o +++ 


Figure 6: Traffic Class Sub-TLV Format 
Type: 4, the Traffic Class Sub-TLV. 
Length: Indicates the length of the Value field in octets (4). 


Traffic Class (TC): Identifies the TC [RFC5462] for periodic 
continuity monitoring messages or packets with fault management 
information. 


If the Traffic Class Sub-TLV is present, then the value of the TC 
field MUST be used as the value of the TC field of an MPLS label 
stack entry. If the Traffic Class Sub-TLV is absent from BFD 
Configuration Sub-TLV or Fault Management Signal Sub-TLV, then 
selection of the TC value is a local decision. 


3.4. Performance Monitoring Sub-TLV 


If the OAM Function Flags Sub-TLV has either the PM/Loss, PM/Delay, 
or PM/Throughput flag set, the Performance Monitoring Sub-TLV MUST be 
present in the MPLS OAM Configuration Sub-TLV. Failure to include 
the correct sub-TLVs MUST result in an "OAM Problem/Configuration 
Error" message being generated. 


The Performance Monitoring Sub-TLV provides the configuration 
information mentioned in Section 7 of [RFC6374]. It includes support 
for the configuration of quality thresholds and, as described in 
[RFC6374], "the crossing of which will trigger warnings or alarms, 
and result reporting and exception notification will be integrated 
into the system-wide network management and reporting framework." 
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In case the values need to be different than the default ones, the 
Performance Monitoring Sub-TLV includes the following sub-TLVs: 


o MPLS OAM PM Loss Sub-TLV if the PM/Loss and/or PM/Throughput flag 
is set in the OAM Function Flags Sub-TLV; and 


o MPLS OAM PM Delay Sub-TLV if the PM/Delay flag is set in the OAM 
Function Flags Sub-TLV. 


The Performance Monitoring Sub-TLV depicted below is carried as a 
sub-TLV of the MPLS OAM Configuration Sub-TLV. 


0 1 2 3 
0123456789 0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Perf. Monitoring Type (2) | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Ip[n|s|v|k]c| Reserved (set to all 0s) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


i sub-TLVs i 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 7: Performance Monitoring Sub-TLV Format 
Type: 2, the Performance Monitoring Sub-TLV. 


Length: Indicates the TLV total length in octets, including sub-TLVs 
as well as Type and Length fields. 


Configuration Flags (for the specific function description please 
refer to [RFC6374]): 


o D: Delay inferred/direct (0-INFERRED, 1=DIRECT). If the egress 
LSR does not support the specified mode, an "OAM Problem/ 
Unsupported Delay Mode" error MUST be generated. 


o L: Loss inferred/direct (0-INFERRED, 1=DIRECT). If the egress LSR 
does not support the specified mode, an "OAM Problem/Unsupported 
Loss Mode" error MUST be generated. 


o J: Delay variation/jitter (1=ACTIVE, O=NOT ACTIVE). If the egress 
LSR does not support Delay variation measurements and the J flag 
is set, an "OAM Problem/Delay variation unsupported" error MUST be 
generated. 
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o Y: Dyadic (1=ACTIVE, O=NOT ACTIVE). If the egress LSR does not 
support Dyadic mode and the Y flag is set, an "OAM Problem/Dyadic 
mode unsupported" error MUST be generated. 


o K: Loopback (1-ACTIVE, O=NOT ACTIVE). If the egress LSR does not 
support Loopback mode and the K flag is set, an "OAM Problem/ 
Loopback mode unsupported" error MUST be generated. 


o C: Combined (1=ACTIVE, O=NOT ACTIVE). If the egress LSR does not 
support Combined mode and the C flag is set, an "OAM Problem/ 
Combined mode unsupported" error MUST be generated. 


Reserved: Reserved for future specifications; set to 0 on 
transmission and ignored when received. 


3.4.1. MPLS OAM PM Loss Sub-TLV 


The MPLS OAM PM Loss Sub-TLV depicted below is carried as a sub-TLV 
of the Performance Monitoring Sub-TLV. 


0 1 2 3 
0123456789 0123456789012345678901 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
PM Loss Type (1) | Length | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
OTF |T|B| Reserved (set to all 0s) 
S — — ++ 
Measurement Interval 
A — 
Test Interval | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Loss Threshold | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ — + — + — + — + — + 


Figure 8: MPLS OAM PM Loss Sub-TLV Format 
Type: 1, the MPLS OAM PM Loss Sub-TLV. 


Length: Indicates the length of the parameters in octets, including 
Type and Length fields (20). 


Origin Timestamp Format (OTF): Origin Timestamp Format of the Origin 
Timestamp field described in [RFC6374]. By default, it is set to 
IEEE 1588 version 1. If the egress LSR cannot support this value, an 
"OAM Problem/Unsupported Timestamp Format" error MUST be generated. 
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Configuration Flags (please refer to [RFC6374] for further details): 


o T: Traffic-class-specific measurement indicator. Set to 1 when 
the measurement operation is scoped to packets of a particular 
traffic class (Differentiated Service Code Point (DSCP) value) and 
zero otherwise. When set to 1, the Differentiated Services (DS) 
field of the message indicates the measured traffic class. By 
default, it is set to 1. 


o B: Octet (byte) count. When set to 1, it indicates that the 
Counter 1-4 fields represent octet counts. When set to 0, it 
indicates that the Counter 1-4 fields represent packet counts. By 
default, it is set to 0. 


Reserved: Reserved for future specifications; set to 0 on 
transmission and ignored when received. 


Measurement Interval: The time interval (in milliseconds) at which 


Loss Measurement query messages MUST be sent in both directions. If 
the egress LSR cannot support the value, it SHOULD reply with a 
supported interval. By default, it is set to 100 milliseconds as per 
[RFC6375]. 


Test Interval: Test messages interval (in milliseconds) as described 
in [RFC6374]. By default, it is set to 10 milliseconds as per 
[RFC6375]. If the egress LSR cannot support the value, it SHOULD 
reply with a supported interval. 


Loss Threshold: The threshold value of measured lost packets per 
measurement over which action(s) SHOULD be triggered. 
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3.4.2. MPLS OAM PM Delay Sub-TLV 


The MPLS OAM PM Delay Sub-TLV depicted below is carried as a sub-TLV 
of the Performance Monitoring Sub-TLV. 


0 1 2 3 

0123456789 0123456789012345678901 

———— — —— — — — — — — — — + 

PM Delay Type (2) | Length 

D — — — I + 

OTF |T|B| Reserved (set to all 0s) 

A A A A A A A A A A —— — — — — — — — — P 

Measurement Interval 
A A A A A ——— ————— — — — — —— A o + + 
Test Interval | 

——————————————— — —— A — — — A o o q 4 +4 
Delay Threshold | 

Stato titi A A A ——— —M—— A —— tata —  —  —— q + + 


+— + — + —+—+—+ 


Figure 9: MPLS OAM PM Delay Sub-TLV Format 
Type: 2, the MPLS OAM PM Delay Sub-TLV. 


Length: Indicates the length of the parameters in octets, including 
Type and Length fields (20). 


OTF: Origin Timestamp Format of the Origin Timestamp field described 
in [RFC6374]. By default, it is set to IEEE 1588 version 1. If the 
egress LSR cannot support this value, an "OAM Problem/Unsupported 
Timestamp Format" error MUST be generated. 


Configuration Flags (please refer to [RFC6374] for further details): 


o T: Traffic-class-specific measurement indicator. Set to 1 when 
the measurement operation is scoped to packets of a particular 
traffic class (Differentiated Services Code Point (DSCP) value) 
and zero otherwise. When set to 1, the Differentiated Service 
(DS) field of the message indicates the measured traffic class. 
By default, it is set to 1. 


o B: Octet (byte) count. When set to 1, it indicates that the 
Counter 1-4 fields represent octet counts. When set to 0, it 
indicates that the Counter 1-4 fields represent packet counts. By 
default, it is set to 0. 


Reserved: Reserved for future specifications; set to 0 on 
transmission and ignored when received. 
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Measurement Interval: The time interval (in milliseconds) at which 
Delay Measurement query messages MUST be sent on both directions. If 
the egress LSR cannot support the value, it SHOULD reply with a 
supported interval. By default, it is set to 1000 milliseconds as 
per [RFC6375]. 


Test Interval: Test messages interval (in milliseconds) as described 
in [RFC6374]. By default, it is set to 10 milliseconds as per 
[RFC6375]. If the egress LSR cannot support the value, it SHOULD 
reply with a supported interval. 


Delay Threshold: The threshold value of measured two-way delay (in 
milliseconds) over which action(s) SHOULD be triggered. 


3.5. MPLS OAM FMS Sub-TLV 


The MPLS OAM FMS Sub-TLV depicted below is carried as a sub-TLV of 
the MPLS OAM Configuration Sub-TLV. When both working and protection 
paths are signaled, both LSPs SHOULD be signaled with identical 
settings of the E flag, T flag, and the refresh timer. 


0 1 2 3 
QUT. 2:.-3-4-5.216 24 8.950 1.«.2. 35 405 06: 8 9:071. 2: 3-4- 5. 6: 78:9 Ona. 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| MPLS OAM FMS Type (3) | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
le|s|T| Reserved Refresh Timer 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


i Sub-TLVs 7 

A RR I ERES 
Figure 10: MPLS OAM FMS Sub-TLV Format 

Type: 3, the MPLS OAM FMS Sub-TLV. 


Length: Indicates the TLV total length in octets, including Type and 
Length fields (8). 


FMS Signal Flags are used to enable the FMS signals at MEPs and the 


server MEPs of the links over which the LSP is forwarded. In this 
document, only the S flag pertains to server MEPs. 
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The following flags are defined: 


E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR) 
Signaling as described in [RFC6427]. The default value is 1 
(enabled). If the egress MEP does not support FMS signal 
generation, an "OAM Problem/Fault management signaling 
unsupported" error MUST be generated. 


S: Indicate to a server MEP that it should transmit AIS and LKR 
Signals on client LSPs. The default value is 0 (disabled). Ifa 
server MEP, which is capable of generating FMS messages, is for 
some reason unable to do so for the LSP being signaled an "OAM 
Problem/Unable to create fault management association" error MUST 
be generated. 


T: Set timer value, enabled by the configuration of a specific 
timer value. The Default value is 0 (disabled). 


Remaining bits: Reserved for a future specification and set to 0. 


Refresh Timer: Indicates (in seconds) the refresh timer of fault 


indication messages. The value MUST be between 1 to 20 seconds as 
specified for the Refresh Timer field in [RFC6427]. If the egress 
LSR cannot support the value, it SHOULD reply with a supported timer 
value. 


The Fault Management Signals Sub-TLV MAY include the Traffic Class 
Sub-TLV (Section 3.3.4.) If the Traffic Class Sub-TLV is present, 
the value of the TC field MUST be used as the value of the TC field 
of an MPLS label stack entry for FMS messages. If the Traffic Class 
Sub-TLV is absent, then selection of the TC value is local decision. 


4. Summary of MPLS OAM Configuration Errors 


In addition to error values specified in [RFC7260], this document 
defines the following values for the "OAM Problem" error code: 


o If an egress LSR does not support the specified BFD version, an 
error MUST be generated: "OAM Problem/Unsupported BFD Version". 


o If an egress LSR does not support the specified BFD Encapsulation 
format, an error MUST be generated: "OAM Problem/Unsupported BFD 
Encapsulation format". 


o If an egress LSR does not support BFD Authentication and it is 


requested, an error MUST be generated: "OAM Problem/BFD 
Authentication unsupported". 
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o If an egress LSR does not support the specified BFD Authentication 
Type, an error MUST be generated: "OAM Problem/Unsupported BFD 
Authentication Type". 


o If an egress LSR is not able to use the specified Authentication 
Key ID, an error MUST be generated: "OAM Problem/Mismatch of BFD 
Authentication Key ID". 


o If an egress LSR does not support the specified Timestamp Format, 
an error MUST be generated: "OAM Problem/Unsupported Timestamp 
Format". 


o If an egress LSR does not support the specified Delay mode, an 
"OAM Problem/Unsupported Delay Mode" error MUST be generated. 


o If an egress LSR does not support the specified Loss mode, an "OAM 
Problem/Unsupported Loss Mode" error MUST be generated. 


o If an egress LSR does not support Delay variation measurements and 
it is requested, an "OAM Problem/Delay variation unsupported" 
error MUST be generated. 


o If an egress LSR does not support Dyadic mode and it is requested, 
an "OAM Problem/Dyadic mode unsupported" error MUST be generated. 


o If an egress LSR does not support Loopback mode and it is 
requested, an "OAM Problem/Loopback mode unsupported" error MUST 
be generated. 


o If an egress LSR does not support Combined mode and it is 
requested, an "OAM Problem/Combined mode unsupported" error MUST 
be generated. 


o If an egress LSR does not support Fault Monitoring signals and it 
is requested, an "OAM Problem/Fault management signaling 
unsupported" error MUST be generated. 


o If an intermediate server MEP supports Fault Monitoring signals 
but is unable to create an association when requested to do so, an 
"OAM Problem/Unable to create fault management association" error 
MUST be generated. 
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5. IANA Considerations 
5.1. MPLS OAM Type 
This document specifies the new MPLS OAM type. IANA has allocated a 


new type (3) from the "OAM Types" space of the "RSVP-TE OAM 
Configuration Registry". 


4£------ 4------------- 4----------- + 
| Type | Description | Reference | 
4£------ 4------------- 4£----------- + 
| 3 | MPLS OAM | [RFC7487] | 
4£------ 4------------- 4£----------- + 


Table 1: MPLS OAM Type 
5.2. MPLS OAM Configuration Sub-TLV 
This document specifies the MPLS OAM Configuration Sub-TLV. IANA has 


allocated a new type (33) from the OAM Sub-TLV space of the "RSVP-TE 
OAM Configuration Registry". 


4+------ 4-------------------------------- 4+----------- + 
| Type | Description | Reference | 
4+------ 4-------------------------------- 4+----------- + 
| 33 | MPLS OAM Configuration Sub-TLV | [RFC7487] | 
4+------ 4-------------------------------- 4+----------- + 


Table 2: MPLS OAM Configuration Sub-TLV Type 


Bellagamba, et al. Standards Track [Page 25] 


RFC 7487 


DD 


IANA has created an "MPLS OAM Configuration Sub-TLV Types" 
registry in the "RSVP-TE OAM Configuration Registry" 
carried in the MPLS OAM Configuration Sub-TLV. 


Extensions for MPLS-TP OAM Configuration 


MPLS OAM Configuration Sub-TLV Types 


March 2015 


sub- 


for the sub-TLVs 
Values from this new 


sub-registry are to be allocated through IETF Review except for the 
"Reserved for Experimental Use" range. 
following types: 


5.4. 


IANA has created a "BFD Configuration Sub-TLV Types" 


4-65532 
| 65533-65534 
| 


[V9] 


65535 


Reserved 


BFD Configuration Sub-TLV 
Performance Monitoring Sub-TLV 
MPLS OAM FMS Sub-TLV 


Unassigned 


Reserved for Experimental Use 


Reserved 


This document defines the 


[RFC7487] 


| 
[RFC7487] | 
[RFC7487] | 
[RFC7487] 


[RFC7487] | 
[RFC7487] | 


Table 3: MPLS OAM Configuration Sub-TLV Types 


BFD Configuration Sub-TLV Types 


the "RSVP-TE OAM Configuration Registry" 


carried in the BFD Configuration Sub-TLV. 


for the sub-TLV types 


registry are to be allocated through IETF Review except for the 
"Reserved for Experimental Use" range. 
following types: 


This document defines the 


4R--——---------- A eec ceci * 
| Type | Description | 
Sama aes acon ada aa aa | al Gigs ca ae achat eiecit munere cue ct EU + 
| 0 | Reserved | 
| Ü | BFD Identifiers Sub-TLV 
| 2 | Negotiation Timer Parameters Sub-TLV | 
| 3 | BFD Authentication Sub-TLV 
4 Traffic Class Sub-TLV 
5-65532 Unassigned 
| 65533-65534 | Reserved for Experimental Use | 
| 65535 | Reserved | 
$ 4-———--—--------------------------------- * 
Table 4: BFD Configuration Sub-TLV Types 
Bellagamba, et al. Standards Track 


Reference 


[RFC7487] 
[RFC7487] 
[RFC7487] 
[RFC7487] 
[RFC7487] 


[RFC7487] 
[RFC7487] 


[Page 


sub-registry in 


Values from this new sub- 


+ 


26] 


RFC 7487 Extensions for MPLS-TP OAM Configuration March 2015 


5.5. Performance Monitoring Sub-TLV Types 


IANA has created a "Performance Monitoring Sub-TLV Type" sub-registry 
in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types 
carried in the Performance Monitoring Sub-TLV. Values from this new 
sub-registry are to be allocated through IETF Review except for the 
"Reserved for Experimental Use" range. This document defines the 
following types: 


4------------- 4------------------------------- 4----------- * 
| Type | Description | Reference | 
4------------- 4------------------------------- 4----------- * 
| 0 | Reserved | [RFC7487] | 
| 1 | MPLS OAM PM Loss Sub-TLV | [RFC7487] | 
| 2 | MPLS OAM PM Delay Sub-TLV | [RFC7487] | 
3-65532 Unassigned 
65533-65534 Reserved for Experimental Use [RFC7487] 
| 65535 | Reserved | [RFC7487] | 
4------------- 4------------------------------- 4----------- * 


Table 5: Performance Monitoring Sub-TLV Types 
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5.6. New RSVP-TE Error Codes 


The following values have been assigned under the "OAM Problem" error 


code [RFC7260] by IETF Review process: 

4-——--------------- pr te ee aS eT ee ee do ENA + 
| Error Value Sub- | Description | Reference | 
| Codes | | | 
4-——--—------------- E O O EE do + 
[ES | Unsupported BFD Version | [RFC7487] | 
| 14 | Unsupported BFD Encapsulation | [RFC7487] | 
| | format | | 
| i5 | Unsupported BFD Authentication | [RFC7487] | 
| | Type | | 
| 16 | Mismatch of BFD Authentication Key | [RFC7487] | 

ID 
| 17 | Unsupported Timestamp Format | [RFC7487] | 
| 18 | Unsupported Delay Mode | [RFC7487] | 
| 19 | Unsupported Loss Mode | [RFC7487] | 
| 20 | Delay variation unsupported | [RFC7487] | 
| 21 | Dyadic mode unsupported | [RFC7487] | 
| 22 | Loopback mode unsupported | [RFC7487] | 
23 Combined mode unsupported [RFC7487] 

| 24 | Fault management signaling | [RFC7487] | 
| | unsupported | | 
| 25 | Unable to create fault management | [RFC7487] | 
| | association | 
4-——--------------- oa SS ASA o ere do + 


Table 6: MPLS OAM Configuration Error Codes 


The "Sub-Codes - 40 OAM Problem" sub-registry is located in the 
"Error Codes and Globally-Defined Error Value Sub-Codes" registry. 


6. Security Considerations 


The signaling of OAM-related parameters and the automatic 
establishment of OAM entities introduces additional security 
considerations to those discussed in [RFC3473]. In particular, a 
network element could be overloaded if an attacker were to request 
high frequency liveliness monitoring of a large number of LSPs, 
targeting a single network element as discussed in [RFC7260] and 
[RFC6060]. 


Additional discussion of security for MPLS and GMPLS protocols can be 
found in [RFC5920]. 
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